Apparatus and method for capacity planning for data center server consolidation and workload reassignment

ABSTRACT

A server migration tool used to construct data center migration scenarios allowing for a user to rapidly manipulate a large number of input parameters required to describe a transformation from one data center configuration to a new data center configuration. The tool then performs the transformation and allows the user to interact with new data center configuration to understand its performance. A novel parameterization, speed independent service demand (SISD), greatly facilitates scaling performance metrics between different hardware platforms.

CROSS REFERENCE TO RELATED APPLICATIONS

The present invention claims priority to U.S. patent application Ser.No. 11/525,511 filed on Sep. 22, 2006 and titled: “Apparatus and Methodfor Capacity Planning for Data Center Server Consolidation and WorkloadReassignment.”

FIELD OF INVENTION

The present invention relates generally to computer server capacityplanning within the field of information technology and morespecifically describes a useful tool by which data center managers canreliably estimate and compare performance of server and workloadmigration scenarios prior to deployment and in production.

BACKGROUND OF THE INVENTION

The performance of large scale production environments is an area ofconsiderable interest as businesses become more diverse and applicationsbecome more complex. Data systems must remain reliable and available.Reliability and performance can be a considerable issue in the face ofrapid system or application scaling such as would be experienced in amerger of two large corporations or in the implementation of a newserver intensive application such as a web media application involvingstreaming video.

A goal of modern capacity planners is to optimize business applicationson very large and complex systems with perhaps thousands of server nodesthat are often geographically dispersed. The workloads processed bythese applications and the infrastructure in which they execute changeover time. New and different users and user behaviors change the leveland mix of the workloads. The servers, networks and their configurationschange for a variety of business reasons. Capacity planners mustdetermine a) the impact of such anticipated or hypothetical changes, b)when anticipated increases in workload levels will exceed the capacityof the existing infrastructure, and c) what solutions to predictedperformance bottlenecks will be most effective. Capacity plannersaccomplish these goals by measuring the current performance of theirbusiness applications, building performance models using thosemeasurements, and using those models to predict how performance willchange in response to anticipated or hypothetical changes to theworkloads and infrastructure.

Server consolidation is one type of change to the IT infrastructure thatoccurs with increasing frequency in order to simplify server management,reduce space and power requirements, and other reasons—includingsimplification and potential improvement of performance management.However, the number of server consolidation options in a modern large ITenvironment is enormous. IT managers and capacity planners cannoteffectively choose among the myriad of server consolidation options bytrial and error or rules of thumb. They need the ability to evaluatedifferent server consolidation scenarios rapidly and easily in order tomake good choices before implementing those choices. The presentinvention provides that ability.

In some situations, low performance of a production system may beanalyzed. To relieve the situation, a workload reassignment or newequipment may be needed. The planning and implementation of the natureof the equipment to be deployed or the workload reassignment requiresassembling a test environment and scaling analysis.

In yet other situations, newer faster equipment may be deployed toreplace older slower equipment. For example, server and storagetechnology are generally replaced every four to five years to takeadvantage of advances in speed, power and efficiency. In this case theIT capacity manager is required to plan a detailed server consolidationwhere the workload of a number of servers is consolidated onto a smallernumber of servers. In the prior art, this type of system consolidationis also carried out with a test environment.

Referring to FIG. 1, a modern large-scale computer network known as aproduction environment is depicted. In a production environment, a datacenter 1 serves as a central repository for distributed applications anddata access to other networks. The data center includes a businessapplication server cluster 2, a database server cluster 3 and a webapplication server cluster 4. The business application server cluster,data server cluster and web application server are interconnected andprovide responses to requests for information from external sources suchas shown at 11 and 12. Requests for information can come from companyintranets such as shown at 5 which support other computer networks. Inthis example, a single company internet can support an operationsnetwork 8, a marketing department network 7 and an execution andfinancial network 6. Requests for information are derived fromapplications running on the various networks which generate workloads.Data center 1 in this example also services requests and providesresponses through the internet 6 to retail customers 10 and othercorporate customers 9.

A general data center server migration situation is shown in FIG. 2A inwhich a source or base data center configuration 20 is to be changed toa destination data center configuration 30. A set of Z workloads 18defined as {w}=w₁, w₂, . . . w_(Z) are arriving at source data centerconfiguration 20 at base arrival rates AB({w}) 15 during a base timeinterval. Workloads 18 are requests for specific computer instructionsto be processed by the base data center. For example, the workloads maybe generated by a number of interne users simultaneously utilizing theirweb browsers to view and interact with web content from a particularcompany's web servers such as viewing catalogs of merchandise,investigating online specifications, placing orders or providing onlinepayments. A destination data center configuration 30 is prescribed toaccept workloads 18 at a set of arrival rates A({w}) 16 where A({w})16is scaled from base arrival rates AB({w}) by some scaling factor G({w}),where G(w)=1 represents the processing of the workloads by thedestination data center configuration at the base (original) workloadarrival rates.

Source data center configuration 20 comprises a set of N server clusters25-1, 25-2, . . . 25-N. Furthermore, server cluster 25-1 comprises a setof server nodes 28-1 and similarly, server clusters 25-1, . . . 25-Ncontain sets of server nodes 28-2, . . . 28-N (not shown). Serverclusters 25-1, . . . 25-N functionally operates to service workloads 18at arrival rates AB({w}) 15. The dimension of a server cluster isdefined as the number of server nodes in the cluster. Source parameters22 describe configuration parameters of the source data centerconfiguration 20.

Destination data center configuration 30 comprises a set of M serverclusters 35-1, 35-2, . . . 35-M. Server cluster 35-1 comprises a set ofserver nodes 38-1 and similarly, server clusters 35-2, . . . 35-Mcontain sets of server nodes 38-2, . . . 38-M (not shown). Serverclusters 35-1, . . . 35-M functionally operates to service workloads 18at arrival rates A({w}) 16. Note that the destination data centerconfiguration 30 may contain a subset of the base server clusters 25-1 .. . 25-M. Furthermore, note that N or M may equal 1 (one) and that thedimension of a given server cluster may equal 1 (one) so that either thesource data center configuration 20 or destination data centerconfiguration 30 may contain only one server node. Destinationparameters 32 describe the source data center configuration 30.

In FIG. 2B, a server node 50 typical of the server nodes in the sourcedata center configuration 20 or of destination data center configuration30. Server node 50 comprises a set of central processing units (CPUs) 55arranged on an appropriate electronics hardware platform (not shown) forexecuting computational and I/O instructions. The hardware platformaccommodates on-board dynamic random-access memory 70 accessible by CPUs55 for dynamic data storage. Attached to CPUs 55 and contained in servernode 50 are a set of disk drives 60 for persistent storage of data andtypically comprised of magnetic read-write hard drives. Also attached toCPUs 55 and contained within server node 50 are a set of networkinterface cards NICs 65 which provide a means by which the CPUs 55attach to networks.

The CPU dimension of a server cluster (e.g. server cluster 25-1) is thenumber of distinct CPUs contained in that server cluster. The disk drivedimension and NIC dimension is similarly defined as the number ofrespective units in a given server cluster.

In migrating from source data center configuration 20 to destinationdata center configuration 30, a potentially large number ofconfiguration parameters 22 and 32 must be specified or computed. Sourceparameters 22 are measured and specified typically as a baseline. It isthe object of the present invention to greatly simplify the process ofmanipulating source parameters 22 by utilizing stored configurations incombination with a set of GUI based wizards for easily specifyingservers and reassigning workloads to transform source parameters 22 intodestination parameters 32. Additionally, workloads 18 may be grown on anumber of time intervals so that the performance sensitivity of thedestination data center configuration 30 to workload may be plotted as afunction of time

The term data center is used throughout this document generally to meanany collection of server clusters organized to perform work on a givenworkload. The data center may be geographically dispersed so that theserver clusters may exist in different geographical locations up to aglobal scale configuration. The term workload reassignment is used todescribe a specific type of data center migration scenario in FIG. 2Aand where a specified fraction of each workload 18 is removed fromsource data center server clusters 25-1,25-N and distributed todestination server clusters 35-1, . . . 35-M. Server consolidationtypically implies a situation where the number of servers or number ofserver clusters are smaller in the destination data center configurationthan in the source configuration, though the present invention appliesequally well when the number of destination servers or clusters islarger. In server consolidation, as defined in this specification, theworkloads from selected source server clusters 25-1, . . . 25-N arefully reassigned and distributed to the destination server clusters35-1, . . . 35-M. The present invention applies more generally tosituations whereby the IT manager desires to understand what theperformance of a new data center configuration will be relative to hiscurrent configuration so as to optimize the new configuration forperformance, cost, upgradeability or other feature. The invention willallow the IT manager to investigate a number of data centerconfiguration scenarios to perform such an optimization. The preferredembodiment of the invention provides the capacity to model serverconsolidation and workload reassignment as well as other situations.

There are a number of products on the market today to aid theperformance engineer in the capacity planning process. Current state ofthe art in capacity planning tools for server consolidation typicallyinclude automatic population of baseline (pre-consolidation) models fromdatabases or performance measurement or monitoring tools. In some casesagents must be present on the monitored devices. Additionally, theseproducts offer rudimentary capabilities to move workloads from one ormore baseline servers to a new server.

In terms of ease of use, the state-of-the-art remains cumbersome. Forexample, when modeling workload and hardware changes in the case ofdissimilar hardware between the source and destination servers, scalingfactors may need to be calculated external to the planning tool andentered by the user. As another example, the display and organization ofscenarios to the user is always done in a flat list.

The present invention, a server migration planning tool, addresses thecumbersome nature of current planning tools by providing a comprehensiveand intuitive GUI/wizard for creating server consolidation scenarios.The wizard steps users through selecting source servers, identifyingand/or creating destination servers, and moving workloads under either aworkload reassignment process or server consolidation process. Multiplereassignments may be combined with a single scenario. The presentinvention provides for flexible grouping of source and destinationservers into tiers of similar servers in a tree list view for ease ofselection.

The present invention also provides the performance engineer withimproved insight by providing for the definition of destination serverswithin a consolidation scenario to be any combination of existing orhypothetical servers. Furthermore, a server may be both a source anddestination for server consolidation or workload reassignment.

In yet another improvement to the art, different workloads or fractionsof workloads may be sent to different destinations in a given scenario;the workload reassignments thus made for the given scenario may precedeany scenario (except the base configuration) or it may follow anyscenario.

In addition to improvements in the ease of use and flexibility ofcapacity planning tools for server migration, the transformation enginein the present invention for transforming a source data centerconfiguration into a new data center configuration provides forsignificant improvement. The transformation calculations automaticallyscale to account for hardware/configuration differences, such aschanging to a different model of computer, adding CPU's, or changingdevice speeds. Furthermore, the calculation of memory utilization afterserver consolidation is a novel and useful feature of the presentinvention.

In the preferred embodiment of the present invention, the descriptionand use of a novel parameterization, speed independent service demand(SISD), greatly facilitates scaling performance metrics betweendifferent hardware platforms. Ordinarily (without SISD), computerperformance models must specify service demands in time units such asseconds, which depend upon the original device speeds. To evaluatewhat-if scenarios involving changes to device speeds, the model mustscale the service demands by the ratios of the old and new device speedswhich require the model to remember the speeds of the original devices.Very complex what-if scenarios such as server consolidation requiremultiple such scalings to be performed carefully. SISD simplifies thecalculations of service times in any computer performance model forwhat-if scenarios involving changes in device speeds or reassignment ofwork to new devices with different device speeds. This inventivetechnique has applicability to performance models of any technology, notjust computer-related technology, where service times depend upon thespeed of the devices being modeled.

SUMMARY OF INVENTION

In one embodiment, the invention is used to create “what if” scenariosto answer business questions related to management or complex productionenvironments, including large scale computer networks.

In one embodiment, the invention collects production data fromperformance management tools known in the art. Examples of datacollection tools include BMC Patrol available from BMC Software ofHouston, Tex., HP Openview, available from Hewlett Packard of Palo Alto,Calif., and Tivoli I™, available from IBM of Armonk, N.Y.

The data collected from these data collection tools include server datasuch as CPU utilization and process queue length, disk data such as busyutilization, average queue length, average read/writes per second andper byte, network data such as bandwidth, network interface cardutilization, send/receive bytes per second, network type, latency andduplexing information and memory data such as memory utilization.

On embodiment of the invention then requires that a model ormathematical simulation of the existing computer system be constructed.In this embodiment, the user is required to define the currentproduction environment through use of a library of infrastructurecomponents or by creation of infrastructure components. This environmentfurther requires the user to define one or more workloads used to drivethe model to produce a baseline forecast which is used to analyzeanticipated future performance of the production environment. Growthrate forecasts can be defined by the user to be constant or variable andthe interval can be defined in weeks, months or years.

Once the baseline system has been defined by the user with theinvention, “what if” scenarios can be built and tested using amathematical model. Possible options for use of the invention include,but are not limited to, finding and consolidating underutilized servers,adding CPUs, adding entirely new hardware, upgrading drives andnetworks, swapping various brands of hardware, changing workloads andmoving workloads from one server to another. The “what if” scenariosallow the user to implement changes to the virtual data center withoutdisrupting the production environment. Independent and interdependentchanges across time can also be modeled in the production environment.

Yet another embodiment of the invention provides graphical reports whichallow the user to evaluate the impact of changes made in themathematical model to predict changes and reactions in the largerproduction system.

BRIEF DESCRIPTION OF DRAWINGS

The disclosed inventions will be described with reference to theaccompanying drawings, which show important sample embodiments of theinvention and which are incorporated in the specification hereof byreference, wherein:

FIG. 1 is a prior art diagram of a data center and applications servicenetwork.

FIG. 2A is a block diagram depicting a server migration from a sourcedata center to a destination data center.

FIG. 2B is a block diagram showing the components of a server nodewithin a data center configuration.

FIG. 3 is block diagram of a server migration modeling tool in thepreferred embodiment of the present invention.

FIG. 4 is a screen shot of a Data Center Modeling Wizard in thepreferred embodiment of the present invention.

FIG. 5 is a screen shot of a Scenario Wizards GUI in the preferredembodiment of the present invention.

FIG. 6 is a screen shot of a Server Consolidation Scenario GUI in thepreferred embodiment of the present invention.

FIG. 7 is a screen shot of a Specify Reassignment Details GUI in thepreferred embodiment of the present invention.

FIG. 8 is a screen shot of a Choose Source Servers GUI in the preferredembodiment of the present invention.

FIG. 9 is a screen shot of a Choose Destination Servers GUI in thepreferred embodiment of the present invention.

FIG. 10 is a screen shot of a New Hypothetical Server GUI server tabview in the preferred embodiment of the present invention.

FIG. 11 is a screen shot of a Hardware configuration GUI in thepreferred embodiment of the present invention.

FIG. 12 is a screen shot of a Create Workload Reassignment Scenario GUIin the preferred embodiment of the present invention.

FIG. 13 is a screen shot of a Specify Reassignment Details GUI in thepreferred embodiment of the present invention.

FIG. 14 is a screen shot of a Select Workload to Reassign GUI in thepreferred embodiment of the present invention.

FIG. 15 is a screen shot of a Select Work to Reassign GUI in thepreferred embodiment of the present invention.

FIG. 16 is block diagram describing the scenario transformation methodand process within the preferred embodiment of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The numerous innovative teachings of the present invention will bedescribed with particular reference to the presently preferredembodiment (by way of example, and not of limitation).

In the preferred embodiment of the present invention, apparatus andmethods for a server migration tool are used to construct data centermigration scenarios. In particular, the server migration tool describedin this specification functions to allow a user to rapidly assemble alarge number of input parameters required to describe a transformationfrom one data center configuration to a new data center configuration.The tool then mathematically performs the transformation and allows theuser to interact with new data center scenario to understand itsperformance.

In the following and throughout the remainder of the document, the term‘server’ is equivalent to ‘server cluster’; ‘source’ configuration is ageneral input configuration, while “base” configuration is a specificsource configuration that includes measured baseline parameters;‘relocation’ configuration is equivalent to ‘destination’ configuration;workload ‘relocation’ is equivalent to workload ‘reassignment’; variable“t” is a general server subscript; variable “s” is a general sourceserver subscript; variable “d” is a general destination serversubscript; variable “k” is a general device subscript; variable “n” is ageneral network subscript; variable “w” is a general workload subscript;and, variable “p” is a time interval subscript.

Table 1 below includes a list of the input parameters in the preferredembodiment required to specify a data center scenario transformationsuch as a server consolidation.

Server parameters in Table 1 are comprised of C1 and C2, the totalnumber of servers in the source configuration and the destinationconfiguration, respectively; NAME(t), an ASCII description of server t;SD(t), the dimension of server t, i.e. the number of server nodes in thecluster; PC(t) the CPU count for server t; SV(t,w), the number of visitsper workload w on server t; CS(t), the CPU speed rating for server t;UMC(t), the measured pre-relocation CPU utilization on server t; P(t,w),the fraction of server t utilization assigned to workload w; MU(t,g),service rate at server t with g CPUs active (values of g range from 1 toPC(t)); MUMAX(t)=MU(PC(t)). The CPU speed ratings CS(5) may be derivedfrom industry standard benchmarks or other sources. The service rateMU(t,g) is 1 (one) for a single CPU and typically increases as thenumber of CPUs increase. The value of MU(t,g) is less than g to accountfor resource contention between chip, cores, and hardware threads, aswell as operating system overhead. In exceptionally inefficientconfigurations, value of MU(g,t) may decrease as g increases. Thepresent invention does not impose any special requirements on the valuesof MU.

Storage parameters in Table 1 are comprised of D1 and D2, the totalnumber of disks in the source configuration and the destinationconfiguration, respectively; ND(t), the number of disks on server t;DISKS(t), a mapping of servers to disks; DD(k), dimension of disk kwhich is typically equal to 1 (one); DV(k,w), the device visit count(disk visit count) per workload w at device k; DS(k), the disk speedrating for disk k; UMD(k), the measured pre-relocation disk utilizationon disk k; DSVR(k)=t, the mapping from Disk k to the server t to whichdisk k is attached.

TABLE 1 Server Parameters C1 number of servers in source configurationC2 number of servers in destination configuration Name(t) name of servert SD(t) dimension of server t PC(t) number of cpu in server t SV(t, w)server t visit count CS(t) cpu rating of server t UMC(t) measured CPUutilization of server t P(t, w) fraction of server t utilizationassigned to w MU(t, g), MUMAX(t) service rate with g CPUs active, MUMAX= MU(t, PC(t)) Storage Parameters D1 number of disks in sourceconfiguration D2 number of disks in destination configuration ND(t)number of disks on server t DISKS(t) mapping of all disks on server tDD(k) dimension of disk k DV(k, w) visit count to disk k DS(k) disk kspeed rating UMD(k) measured utilization of disk k DSVR(k) maps a disk kto the server it is attached NIC Parameters N1 number of NICS in sourceconfiguration N2 number of NICS in destination configuration NN(t)number of NICS on server t NICS(t) mapping of all NICS on servers tDD(k) dimension of NIC k DV(k, w) visit count to NIC k NS(k) NIC k speedrating UMN(k) measured utilization of NIC k DSVR(k) maps a NIC k to theserver it is attached Memory Parameters MC(t) memory capacity of servert in GB MCORE(t) memory consumption of server t inactive MFIXED(t) fixedmemory consumption of applications MDYN(t) dynamic memory consumption ofapplications UMM(t) memory utilization on server t MP(t) memory usage onserver t in GB SFM(s, d) memory use scaling factor source to destinationWorkload Parameters Z number of workloads p0 baseline time interval ptime interval index AB(w) base configuration workload arrival rate G(w,p) growth in arrival rate for w in interval p Network Parameters R(k, w)latency or response time NV(n, w) the number of messages per job w TS(n)transmission speed in bits/second SC(n) number of network streams UDR(n,w) data rate for workload w on network n bits/second

NIC parameters in Table 1 are comprised of N1 and N2, the total numberof NICs in the source configuration and the destination configuration,respectively; NN(t), the number of NICs on server t; NICS(t), a mappingof servers to NICs; DD(k), dimension of NIC k; DV(k,w), the device visitcount (NIC visit count) per workload w at device k; NS(k), the NIC speedrating for NIC k; UMN(k), the measured pre-relocation NIC utilization onNIC k; NSVR(k)=t, the mapping from NIC k to the server t to which NIC kis attached.

Memory parameters in Table 1 are comprised of MC(t), the memory capacityfor server t in GB; MCORE(t), memory consumption of server t on aninactive system; MFIXED(t), fixed memory consumption of workload w onserver t, i.e. applications are loaded on server t but not active;MDYN(t), dynamic memory usage on server t; UMM(t), memory utilization onserver t; MP(t), memory usage in gigabytes (GB) on server t; SFM(s,d),memory use scaling factor between source and destination servers. Notethat dynamic memory usage MDYN(t) will increase as the workload arrivalrate increases.

Workload parameters in Table 1 are comprised of W, the number ofworkloads; AB(w), the source arrival rate for workload; a baselineinterval p0, which defines the time interval during which the variousresource consumptions associated with the source are measured; p, aforecast interval that specifies a time interval in the future relativeto the baseline interval p=0; and G(w,p), growth factor for workload win time interval p. Note that A(w,p) is the calculated destinationarrival rate at server t in time interval p and is defined asA(w,p)=G(w,p)*AB(w).

The servers are assumed to be connected via networks. Networks consistof a delay device and a transmission device. These two devices areanalogous to devices (CPU, disk, NIC) on a server. Networks are notaffected by server consolidation or workload reassignment scenarios.However, network characteristics can be altered in a generalconfiguration scenario. Network parameters are comprised of: the latency(or response time) of a network device k, R(,w) for a single networkmessage; the number of messages per job, NV(n,w); the transmission speedin bits/second (or some multiple thereof, such as megabits/second),TS(n); the number of network streams, SC(n); and, the data rate used forworkload w on network n (also in bits/second), UDR(n,w). A network delayis modeled as two parts; a latency delay and a transmission queue. Thetransmission queue has parameters much like a disk, including measuredutilization and speed rating. A network visit count parameter applies toboth the latency and transmission parts. A collection of delaysfixed-rate and load-dependent devices representing components of theinfrastructure can be included in the model. In the preferred embodimentof the present invention, a network delay element can be thought of as adelay device which imposes a fixed delay on every transaction associatedwith a workload w, regardless of the number of transactions. Thetransmission element captures the finite transmission capacity of thenetwork. Other embodiments may explicitly associate delay devices withNICs or other networked components.

The set of parameters described in Table 1 sufficiently defines a modeluseful for performance analysis and calculating a transformation betweena source data center configuration and a destination data centerscenario. Furthermore, the output of the transformation is a newinstance of parameters that sufficiently describe the destination datacenter scenario for performance analysis by a standard queuing theorysolver. A base data center configuration is a special configuration ofparameters, where most of the parameters have been taken from actualmeasured data on a given data center configuration. Modifications to abase data center configuration are called destination data centerscenarios or derived data center scenarios, which come in several types.In one embodiment of the invention, the scenario types of interest areserver consolidation and workload reassignment scenarios. In whatfollows, a source server is defined as a server of the source datacenter configuration and a destination server is defined as a serverwithin the destination data center.

FIG. 3 describes the function of server migration tool 200 of thepresent invention within the present embodiment. Server migration tool200 is an apparatus, comprised of a modern computer (not shown) withdynamic RAM, a display device, a keyboard device, a pointing device(mouse) and a hard drive for data and program storage, on which aprogrammed set of software instructions are operated to implement thefunctional arrangement shown in FIG. 3. In the preferred embodiment ofthe present invention, the server migration tool 200 utilizes a capacityplanner program 205 to provide a user interface to gather user input 208and which contains certain inherent and useful functions such as readingand storing data files, facilitating communications between functionalmodules, displaying results on the display device and operating amodeling engine. Capacity planner 205 is a software framework for thefunctional components of server migration tool 200.

In addition to capacity planner 205, server migration tool 200 usesstored scenarios 220 which comprises a BASE data center configuration225-0 and a set of S derived data center scenarios 225-1, 225-2, . . .225-S. S may be zero, in which case there are no derived data scenarios,however BASE data center configuration 225-0 is required by thepreferred embodiment of the present invention. BASE data center scenario225-0 is constructed from measured data 228 in combination with userinput data 227 and stored prior to invoking server migration tool 200.Measured data 228 is data taken on an actual data center implementationeither in production or in a test environment using tools and methodswell-known in the art, for example, IBM Tivoli Monitoring Tool (TivoliI™) or HP Openview. Examples of measured data are the measuredutilizations UMC(t), UMD(t) and UMN(k), the network response times,R(k,w), workload arrival rates AB(w), visit counts per workload SV(t,w)and DV(k,w). User input data 227 is data generated and stored by a user,for example, in a spreadsheet and contains such information as the namesof the servers, NAME(t), number of servers C1, the number of disks D1,mapping between servers and disks, DISKS(t), server dimensions SD(t),processor counts PC(t), CPU and disk speed ratings CS(t) and DS(k),memory capacities MC(t), and so forth. Stored scenarios 220 aretypically stored on an internal hard drive of the host computer.

Capacity planner 205 contains a selected source data centerconfiguration 230, stored temporarily as an input source of parameters,a data center modeling wizard 210 for servicing user input 208 and forprocess control, a set of configuration and workload reassignment GUIs240 for collecting and organizing source and destination data centerparameters, a transform engine 250 for creating a destination datacenter scenario from a source data center scenario, a destination datacenter scenario 255 stored temporarily as an output of transform engine250, a modeling engine 260 for computing performance results, and a setof performance results 265 stored temporarily as an output of modelingengine 260.

Data center modeling wizard 210 is invoked by capacity planner 205 todestination data center scenario 255 utilizing various inputs andselections from a user. With user input 208 via the keyboard or mouse ofthe given apparatus, data center modeling wizard 210 guides a user ofthe present invention in selecting a source data center scenario orconfiguration from stored scenarios 220. Once the selection is made,data including parameters as described in Table 1 are loaded into sourcedata center configuration 230. Typically, a user will begin by selectingthe BASE data center scenario 225-0 and build a set of derived(destination) data center scenarios 225-1, . . . 225-S investigating andcomparing the performance of the derived data center scenarios with eachother and with the BASE data center scenario 225-0. Data center modelingwizard 210 functions to generate a set of configuration and workloadreassignment GUIs 240 to establish the desired input parameters forcreating the destination data center scenario 255. Once the inputparameters are created data center modeling wizard 210, through userinput 208 invokes transform engine 250 to generate destination datacenter scenario 255. Data center modeling wizard 210 stores the newlygenerated destination data center scenario 255 in stored scenarios 220.Finally, data center modeling wizard 210 displays performance results265. In the preferred embodiment, performance results 265 are displayedin a set of graphic reports which facilitate easy and rapidcomprehension by the user.

Configuration and workload reassignment GUIs 240 function to allow auser to create the input parameters for destination data center scenario255 by easily specifying changes to the existing configuration in thesource data center configuration 230. Examples of such changes includethe selection of servers Select servers from which work is to be movedand to which work is to be moved, the addition of new servers, andgrowth rates of workload arrival rates. More specifically, configurationand workload reassignment GUIs 240 function to populate the elements ofa mathematical transformation matrix that is used by transform engine250 to generate destination data center scenario 255. GUIs 240 will befurther described in connection with FIGS. 5 through 15.

The function of transform engine 250 is to generate a set of parameterssuitable for use by modeling engine 260 to create predicted throughputsand utilizations corresponding to the destination scenario inputparameters set by GUIs 240. The operation and algorithms of transformengine 250 will be described fully below.

The function of modeling engine 260 is to apply the methodology ofstandard queuing theory solver to take baseline configuration parameterssuch as those shown in FIG. 2 and generate standard outputs. Thesestandard outputs include throughputs, utilizations, populations (meansand distributions) and mean response times for each device for eachworkload. The specific apparatus and methods of the modeling engine 260and the graphical user interface to select specific forms of output areknown in the art. One example utilized in the present invention is IPSCapacity Manager available from Hyperformix of Austin, Tex.

To those skilled in the art, usage of a windows oriented graphical userinterface, such as the opening and usage of data center modeling wizard210 is done in a manner common among software applications with a GUI.The application is opened from a menu or by double clicking on anapplication icon. Then the user selects and opens data center modelingwizard 210 using buttons, menus and forms much like one opens a documentin any other application. When data center modeling wizard 210 has beenopened, a screen such as Data Center Modeling screen 300 in FIG. 4 isdisplayed on the host machine.

Turning then to FIG. 4, the portion of the screen on the left is a groupbox 310 labeled “Scenarios”. The group box 310 lists all of the storedscenarios 220 that are available for selection. The stored scenarios 220are organized in a tree structure list that illustrates the derivationrelationship between scenarios. The scenario represented by a child nodeis an extension of the scenario represented by its parent node. That is,the child node scenario definition starts with the parent scenariodefinition and extends that definition with additional user definedmodifications. For example, in the tree shown, the definition ofscenario “GB Network” is the definition of the “Base Configuration”,plus the changes specified in the “Double hyperformix-db and fix memory”scenario, plus the changes specified in “Double hyp-app slower NIC”scenario, plus the changes specified in the “Gb Network scenario”. Thisapproach allows a complex scenario to be built out of a series of smallchanges and makes it easy to see what has changed between scenarios.

Any of stored scenarios 220 shown in group box 310 of FIG. 4 can be thestarting point for a new server consolidation or workload reassignmentscenario, i.e. destination data center scenario 255. To begin defining anew scenario, a user clicks on the scenario to be used as the startingpoint such that it is highlighted, then clicks either the New button 314or the Extend button 312. The two buttons have a similar effect: in whatfollows it is assumed that the Extend button 312 is clicked. Thefunction of Edit button 316 will be described later in the document.Selection of the New Button 314 forces the selection of the Baseconfiguration shown in group box 310 as the starting scenario, otherwisethe subsequent behavior is identical to selecting the Extend button 316.

When Extend button 312 is clicked, a particular configuration andworkload reassignment GUI 240 called the Scenario Wizards GUI is opened.Scenario Wizards GUI 320 is shown in the screen shot of FIG. 5 and isthe first of several GUIs 240 involved in a process that will bedescribed further. A user clicks on Server Consolidation button 323 tocreate a server consolidation scenario or clicks on WorkloadReassignment button 324 to create a workload reassignment scenario. Tosimply change the server or network configuration parameters of ascenario, for example, upgrading a CPU to a server, a user clicks onConfiguration Changes button 321. To set growth parameters and timeintervals to effect workload changes in the model a user clicks onWorkload Changes button 322. Note that Configuration changes andWorkload changes can be done as extensions to other scenarios, includingas extensions to previously generated Server Consolidation or WorkloadReassignment Scenarios.

When the Server Consolidation button 323 is clicked, the Create ServerConsolidation Scenario GUI 330 appears as shown in FIG. 6. A user entersthe scenario name in box 331 and a scenario description in box 332 andcreates one or more reassignments using the New button 335. It is in thereassignments process where the server consolidation is specified.Server consolidation involves moving the work from one or more existingsource servers to one or more existing or hypothetical destinationservers. A list of desired reassignments of work from old servers to newservers is input in dialog box 333. Alternatively, if reassignments havebeen previously defined, the Edit button 336 will become active and theuser can choose to edit an existing reassignment instead of creating anew one from scratch.

When the New button 335 is clicked, a Specify Reassignment Details GUI340 is opened as shown in FIG. 7. The reassignment is given a name andan optional description for future reference by typing a name in box 341and a description in box 342. The Next button 345 is clicked to move tothe next step in the reassignment process which is to choose the sourceservers for which all work is to be moved to the destination servers.

When the Next button 345 is clicked, Choose Source Server GUI 350 opensas shown in FIG. 8. The Choose Source Servers GUI 350 is used to selectthe set of servers from the source scenario for which the work is to bemoved. The Choose Source Servers GUI 350 lists in tree view 351, theavailable infrastructure servers in the source data center configuration230 organized by tier. If a tier was not previously designated for aserver, data center modeling wizard 210 groups those servers under a ‘NoTier’ node in tree view 351 (not shown). A tier is a collection ofsimilar server types, for example, the APP tier shown in tree view 351is a collection of application servers and the DB tier is a collectionof database servers. One or more servers or tiers of servers are addedto the Selected source servers list 352 by clicking on the name so thatit is highlighted and then clicking on the ‘>>’ button 353. The ‘<<’button 354 is used to delete source servers from the Selected sourceservers list 352. In some cases the list of available servers may bequite large. In the preferred embodiment, a filter function on availableservers is provided by typing a wildcard (*) symbol or question mark (?)symbol in combination with search strings into the filter box 356. As anexample, use *web* to select server names that contain the word websomewhere in the name, use web* to select all server names that beginwith web, or use *web to select all server names that end with web. Usew?b to select server names that match web, wab, or wxb. You can combinethe * and ? wild cards in a pattern. Data center modeling wizard 210reassigns resource consumption attributable to all workloads defined onthe chosen source servers to the destination servers (yet to bedefined). The Next button 355 is selected to move to the next step inthe reassignment process which is to choose the destination servers forthe destination data center scenario 255.

When the Next button 355 is clicked, Choose Destination Server GUI 360opens. FIG. 9 shows the Choose destination servers GUI 360 whichoperates to allow for the selection of destination servers for thedestination data center scenario 255 by creating a list of selecteddestination servers 362 from the set of available servers 361, which inthe preferred embodiment of the present invention, is the set of serversin the source data center scenario 255. In contrast to GUI 350, “New”button 364 is utilized in GUI 360 to create a new hypothetical serverwhich may be included in the destination servers list 362. The server issaid to be hypothetical because it represents a server that is not partof the base configuration of source data center configuration 230 andthere is no performance data available on this server to represent abaseline workload. When the Finish button 365 is clicked on the Choosedestination servers GUI 360, the scenario definition is saved if validand the Data Center Modeling Screen 300 is displayed.

The New Hypothetical Server GUI 370 a shown in FIG. 10 appears when“New” button 364 is clicked and serves to allow a user to define a modelof a server including disk drives and NICs that may be associated withit. The server tab 371 or hardware configuration tab 372 is selectedaccording to which parameters are currently of interest. The screen shotin FIG. 10 coincides with the server tab 371 enabled so that variousserver functions may be defined. A server name is specified in box 373.Devices button 374, upon being clicked opens a dialog box (not shown) toallow for selection of disk drives and NICS: at least one disk and oneNIC must be selected for the hypothetical server to be valid; themappings to the new hypothetical server are held in DISKS(k) or NICS(k).A threshold profile table 375 is defined by either selecting an existingprofile from drop down menu 376 or by clicking New button 377 to createa new threshold profile. Threshold profile table holds high and lowthreshold utilizations for CPU, Disk I/O, NIC I/O and memory. The newhypothetical server may be assigned to a network tier by using drop downmenu 378 or clicking New button 379 to create a new tier. Multithreadingmay be enabled in the server model by checking check box 380.

If the user clicks Hardware configuration tab 372, a correspondingHardware configuration GUI 370 b is opened to allow the user to specifyhardware details in the hypothetical server model. Hardwareconfiguration GUI 370 b is shown in FIG. 11 and is used to specify ahardware model by selecting from drop down menu 381 or creating a newmodel by clicking New button 382. Hardware configuration GUI 370 b isalso used to set the number of CPUs, CP(h), in box 383; dimension SD(h),in box 384; total memory MC(h), in box 385; fixed memory utilization,MFIXED(h) in box 386; NIC speed, NS(h) in box 387; absolute disktransfer speed in box 388; and the use of a RAID array in checkbox 389.The subscript h represents the subscript assigned by data centermodeling wizard 210 to the new hypothetical server thereby created. Whenall dialog boxes have been filled, the GUI form is submitted by clicking“on” button 390. The selection of these parameters and the serverparameters is straightforward to those skilled in the art of computerperformance modeling and will not be described in more detail here. Itis relevant to the present invention that destination data center servermodels may be created out of existing server models or new hypotheticalserver models so that server consolidation scenarios may be fullyexplored by the user.

In the preferred embodiment of the present invention, a general WorkloadReassignment scenario may be created as the destination data centerscenario 255. Beginning with the Scenario Wizards GUI 320 of FIG. 5, theWorkload Reassignment button 324 is selected to open a Create WorkloadReassignment Scenario GUI 400 which is shown in FIG. 12. A user entersthe scenario name in box 401 and a scenario description in box 402 andcreates one or more reassignments using the New button 405. In eachreassignment a user can specify the reassignment of single workload. Theworkload can be moved from one or more source servers to one or moredestination servers. The user can choose to move only a fraction of theworkload from any of the source servers. In contrast to the ServerConsolidation process in which all workloads associated with a serverare reassigned, the Workload Reassignment process allows a user to builda complex reassignment of work from source to destination as needed.Alternatively, if reassignments have been previously defined, the Editbutton 406 will become active and the user can choose to edit anexisting reassignment instead of creating a new one from scratch.

When the New button 405 is pressed, a Specify Reassignment Details GUI410 is opened as shown in FIG. 13. The reassignment is given a name andan optional description for future reference by typing a name in box 411and a description in box 412. The Next button 415 is selected to move tothe next step in the Workload Reassignment process which is to choosethe workload reassigned to the destination servers.

When Next button 415 is clicked, the Select Workload to Reassign GUI 420is opened and appears as shown in FIG. 14. GUI 420 simply shows a listof workloads 421 that exist in the source data center scenario. Thedesired workload is selected and the Next button 425 is clicked toinvoke the Choose Source Servers GUI 350 which operates in the same wayas previously described.

When the Choose Source Servers GUI 350 closes under the WorkloadReassignment process, the Select Work to Reassign GUI 430 of FIG. 15automatically opens. Referring to FIGS. 14 and 15, each source serverselected in Choose Source Servers GUI 350 is shown in the Server list431 and in its corresponding row, the metrics Available % 432, Reassign% 433 and Remainder % 434. Available % 432 lists the percentage ofworkload that is not already reassigned in other reassignments such asin the Select Workload to Reassign GUI 420. Reassign % 433 lists thepercentage of original workload to reassign. Original workload means theworkload before any reassignments are made in the original source datacenter configuration 230. The default for Reassign % 433 is all of theavailable work—the amount to reassign cannot exceed the amountavailable. Remainder % 434 lists the percentage of original workloadleft on the source server after the reassignment. To designate thereassignment, one an amount to reassign is typed into box 436. Then theFill all button 437 is clicked to effect the reassignment for all of thelisted servers. Alternatively, the user can type a value directly intothe Reassign % 433 column in the desired row.

Upon completion of the Select Work to Reassign GUI 430 the processcontinues by opening the Choose destination servers GUI 360 whichoperates in the manner previously described to select a list ofdestination servers to include in the destination data center scenario255. When the user clicks either the Finish button 440, or the Nextbutton 435, the destination data center scenario is saved. Data Centermodeling wizard 210 reassigns all resource consumption attributable tothe workloads specified for reassignment in Select Work to Reassign GUI430 from the source servers in source data center configuration 230 tothe destination servers in destination data center scenario 255. In thepreferred embodiment of the present invention, the reassigned workloadis automatically distributed uniformly across the destination servers indestination data center scenario 255.

The editing of existing scenarios is done by selecting a scenario on theData Center Modeling screen 300 (FIG. 4) and clicking the Edit button314 under the scenario tree. This action will display the appropriateform for editing the scenario definition. The GUIs 240 used for editingscenarios are identical to the GUIs 240 used for creating new scenariosexcept for the GUI title and except that the GUIs 240 are pre-populatedwith the information the user previously specified in the definition.

Within the present invention, other interfaces are possible forrepresenting server consolidation. One such approach is the use of known“drag and drop” GUI technology to “drag” one server on top of another torepresent the reassignment of work from one computer to the other. Inthe case of workload reassignments, workloads would be dragged ratherthan servers. In the preferred embodiment the workloads are distributeduniformly across destination servers. Several other kinds ofdistribution of that work are easily implemented, including distributionaccording to destination resource capacity and proportional distributionexplicitly specified by a user. The workload distribution could also bespecifiable for each device.

Moving to FIG. 16, a description now follows of the preferredtransformation method and process 500 of the present invention fortransforming the server consolidation and workload reassignment scenariospecifications and source data center configuration 230 parameters intonew destination data center scenario 255 parameters. Both the sourceparameters and the destination parameters are suitable inputs for astandard queuing network model solver.

The transformation method and process 500 is summarized in FIG. 16. Thefirst step 510 in the transformation method 500 is to calculate athroughput per device in the source configuration:TPUT(k,w)=AB(w)*DV(k,w).

In the prior art of performance modeling, resource consumption isspecified by the service demand and workload arrival rates. The servicedemand is the amount of processing time required for each workload oneach visit to a given device with the use of the invention. However, itis possible to estimate service demands from device utilization anddevice efficiency parameters.

In step 520 of the transformation method 500, service demands areestimated for source data center configuration 230. Basic formulae forestimating service demands from measured utilization on an SMP systemare:

${{{PDC}\left( {s,w} \right)} = \frac{{{UMC}(s)} \star {P\left( {s,w} \right)} \star {{{MU}{MAX}}(s)}}{{{AB}(w)} \star {{DV}\left( {s,w} \right)}}};$${{{PDD}\left( {k,w} \right)} = \frac{{{UMD}(k)} \star {P\left( {k,w} \right)}}{{{AB}(w)} \star {{DV}\left( {k,w} \right)}}};{{{and}{{PDN}\left( {k,w} \right)}} = \frac{{{UMN}(k)} \star {P\left( {k,w} \right)}}{{{AB}(w)} \star {{DV}\left( {k,w} \right)}}}$where PDC(s,w) is the server demand for source servers for the server sand the workload w; where PDD(k,w) is the source device demand forsource disks for the device k and the workload w; and where PDN(k,w) isthe NIC source demand for the source NICs for the device k and theworkload w.

The memory service demand PDM(s,w) must be calculated from the measuredmemory usage during the baseline source interval. The units of memoryservice demand are Gigabytes per visit per second. Note that visits persecond are the units of arrival First, the static components of memoryusage must be removed to arrive at the total dynamic memory consumption.

${{MDYN}\left( {s,0} \right)} = {{{MP}(s)} - {\left( {{{MCORE}(s)} + {\sum\limits_{w}{{MFIXED}\left( {s,w} \right)}}} \right).}}$

Next, dynamic memory is allocated among workloads in the sameproportions as CPU usage.MDYN(s,w)=MDYN(s,0)*P(s,w).Dividing MDYN(s,w) by the baseline throughput yields the memory demandfor destination server d

${{PDM}\left( {s,w} \right)} = {\frac{{MDYN}\left( {s,w} \right)}{{TPUT}\left( {s,w} \right)}.}$

In another embodiment of the present invention the fractional valuesequivalent to P(s,w) for memory may be set explicitly, and in yetanother embodiment the fractional values are measured fromworkload-memory statistics. In step 530 a of the transformation method,a decision is made to execute either step 530 b or step 530 c. If theserver consolidation process has been used to specify destination datacenter scenario 255, then step 530 b is executed. If the workloadreassignment process has been used to specify destination data centerscenario 255, then step 530 c is executed

The steps 530 b and 530 c of the transformation method 500 compute aserver transformation matrix F(s,d,w). Workload relocation is specifiedby a three dimensional array F(s,d,w): the fraction of workload w to berelocated from source server s to destination server d. Values of F mustrange between 0 and 1. Since work is neither created nor removed byrelocation, it must be true that the total activity for each workload isthe same before and after relocation:

${\forall{s{\forall{w{\sum\limits_{d = 1}^{C\; 2}{F\left( {s,d,w} \right)}}}}}} = 1.$

If no workload relocation is done, the value of F (s,d,w) is 1 when s=dand 0 otherwise.

In step 530 b, in which case a server consolidation scenario specifiesthe destination data center scenario 255, the server transform matrix Ftakes on the values:

${F\left( {s,d,w} \right)} = {\frac{1}{{NDS}(s)}.}$where NDS(s) is the number of destination servers per source server s.NDS(s) is derived from the specification of the server consolidationscenario. For example, if a user specifies that server s is to be“consolidated” onto servers d1 and d2, then NDS(s)=2. In serverconsolidation scenarios, the value of F(s,d,w) is the same for allworkloads.

In step 530 c, in which case a workload reassignment scenario specifiesthe destination data center scenario 255, the value of F(s,d,w) is:

${F\left( {s,d,w} \right)} = {\frac{{RP}\left( {s,w} \right)}{100}{\frac{1}{{NDS}(s)}.}}$where RP(s,w) is the relocation percentage for workload w on server sspecified in the workload reassignment GUI 430 and NDS(s) is specifiedin choose source server GUI 350 and choose destination servers GUI 360.For workload reassignment scenarios, the value of F can vary betweenworkloads.

In the computations that follow, the value of F(s,d,w) is applieduniformly to all resources. For example, if 20% of a workload's CPUactivity is to be relocated to a destination server, then 20% of itsdisk and NIC activity must be relocated to the same destination serveras well.

Since each server can have multiple disks and NICs, a device transfermatrix is needed to govern how the input/output activity associated witha given source-to-destination server pair and workload will be allocatedto multiple peripherals on the given destination server.

In step 540 of the transformation method 500, the fraction of relocatedworkload w moved from disk i to disk j, BD(i,j,w), is computed.BD(i,j,w) is multiplied by the fraction F (s,d,w) of work moved fromsource server s to destination server d to determine the fraction of theoriginal workload moved from device i to device j.

Values in the BD array are subject to the constraint that 100% of everyworkload for every source disk i must be assigned to some disk.

${\forall{i{\forall{w{\sum\limits_{j = 1}^{j = {D\; 2}}{{BD}\left( {i,j,w} \right)}}}}}} = 1.$

The no-relocation case is:

-   -   ∀i ∀j ∀w BD(i,j,w)=1 if i=j,0 otherwise.

The array BN provides similar information for NICs. In the currentimplementation, work on disks and NICs is spread uniformly across alldestination devices according to:

${{{BD}\left( {i,j,w} \right)} = \frac{1}{{ND}\left( {{DSVR}(j)} \right)}};{and}$${{BN}\left( {i,j,w} \right)} = {\frac{1}{{NN}\left( {{NSVR}(j)} \right)}.}$

In step 550 of transformation method 500, destination data centerscenario 255 arrival rates are computed taking into account the givenworkload growth, G(w,p): A(w,p)=AB(w)*G(p,w).

In step 560 of the transformation method, speed independent servicedemands for the source servers and devices are computed from the rawservice demands of step 520. In order to handle speed differencesbetween servers, it is useful to define the parameter speed independentservice demand (SISD). Using such SISD parameters in workload relocationcalculations eliminates the need to scale the contributions from eachsource server by that servers speed. The SISD is defined as

CPU: SIDC(t,w)≡CS(t)*PDC(t,w);

Disk: SIDD(k,w)≡DS (k)*PDD(k,w); and

NIC: SIDN(k,w)≡NS(k)*PDN(k,w)

The SISD parameter is a novel concept. The SISD technique converts theoriginal service demands to a speed-independent form that avoids thecomplex conversions and bookkeeping. The SISD technique combines aperformance rating, such as a SPEC rating for a computer processor, witha demand measurement in units of time to arrive at a scaling parameter.For instance, a service demand of three seconds for a CPU device with aSPEC rating 1000 is converted to a service demand of 3000 SPEC-seconds,which is now independent of the original device speed. If a what-ifscenario replaces the original device with a 2000 SPEC rating device,the new service demand is still 3000 SPEC-seconds. The service TIME willbe reduced from three seconds to 3000 SPEC-seconds/2000 SPEC=1.5seconds. In complex what-if scenarios such as server consolidation, thespeed-independent service demands can be moved or added in astraightforward way.

In brief, SISD simplifies the calculations of service times in anycomputer performance model for what-if scenarios involving changes indevice speeds or reassignment of work to new devices with differentdevice speeds.

This technique has applicability to performance models of anytechnology, not just computer-related technology, where service timesdepend upon the speed of the devices being modeled. For example, for amachine with a performance rating in horsepower, the SISD parameterwould be horsepower seconds. Similarly, for a machine with a performancerating in revolutions per minute (RPM), the SISD parameter would be RPMseconds. As a further example, for a job task with a performance ratingof man hors, the SISD parameter would be man hour seconds. Of course,those skilled in the art will recognize that the time parameter givenhere as “seconds” can take on other units of time as is convenient forthe problem definition at hand.

In the preferred embodiment of the present invention, workloadreassignments are represented by adjusting the visit counts of eachserver. Initially, each server has a visit count of 1. In step 570 ofthe transformation method 500, the destination data center scenario 255device visit counts are adjusted according to workload reassignmentparameters and for dimension. Some definitions of visit count parametersthat will be used in the calculations to follow are shown in Table 2.

TABLE 2 SVCU(t, w) Server visit counts for server t and workload wwithout considering server dimension SVCD(t, w) Server visit counts forserver t and workload w considering server dimension DVCU(i, w) Devicevisit counts for device I and workload w without considering dimensionDVCD(i, w) Device visit counts considering dimension PSVU(t, w) Servervisit counts, without dimension, before a relocation RSVU(t, w) Servervisit counts, without dimension, after a relocationIn a non-relocation scenario, all visit counts are 1:PSVU(t,w)=RSVU(t,w)=1.The new visit count in a relocation scenario is calculated by summingthe contributions from each source server:

${\forall{d{\forall{{wRSVU}\left( {d,w} \right)}}}} = {\sum\limits_{s = 1}^{C\; 1}{{{PSVU}\left( {s,w} \right)} \cdot {{F\left( {s,d,w} \right)}.}}}$As indicated by the above calculations, any of the source servers canalso be a destination server in the preferred embodiment of the presentinvention.

If a server has a dimension greater than one, then the visit count isreduced according to:SVCD(t,w)=RSVU(t,w)/SD(t).

The relevant device visit count is the device visit count adjusted forthe device dimension. For disks and NICs:

${{DVCD}\left( {k,w} \right)} = {\frac{{RSVU}\left( {{{DSVR}(k)},w} \right)}{{{DD}(k)} \star {{SD}\left( {{DSVR}(k)} \right)}}.}$

In step 580 of the transformation method, the weighted average speedindependent service demands (SISD) for the destination servers anddevices are computed. Both raw service demand and SISD will vary acrosssource devices. In the case where workload is relocated to a destinationserver from more than one source, it is necessary to construct aweighted average SISD for the destination server. Such a weightedaverage only accounts for possible differences in SISD between sourceservers/devices and is not intended to capture the effects of workloadreassignment. The source SISD is weighted according to the source'scontribution to the relocation multiplier. The weighted SISD for thedestination servers is:

${\forall{d{\forall{{wSIDC}\left( {d,w} \right)}}}} = {\frac{\sum\limits_{s = 1}^{C\; 1}{{{SIDC}\left( {s,w} \right)} \cdot {{PSVU}\left( {s,w} \right)} \cdot {F\left( {s,d,w} \right)}}}{\sum\limits_{s = 1}^{C\; 1}{{{PSVU}\left( {s,w} \right)} \cdot {F\left( {s,d,w} \right)}}}.}$

The weighted SISD for the destination disks is:

∀d ∀j E DISKS(d) ∀w.

${{SIDD}\left( {j,w} \right)} = {\frac{\begin{matrix}{\sum\limits_{s = 1}^{C\; 1}{\sum\limits_{i \in {{DISKS}{(s)}}}{{{SIDD}\left( {j,w} \right)} \cdot {{PSVU}\left( {{{DSVR}(i)},w} \right)} \cdot}}} \\{{F\left( {s,d,w} \right)} \cdot {{BD}\left( {i,j,w} \right)}}\end{matrix}}{\begin{matrix}{\sum\limits_{s = 1}^{C\; 1}{\sum\limits_{i \in {{DISKS}{(s)}}}{{{PSVU}\left( {{{DSVR}(i)},w} \right)} \cdot}}} \\{{F\left( {s,d,w} \right)} \cdot {{BD}\left( {i,j,w} \right)}}\end{matrix}}.}$

The weighted SISD for the destination NICS is:

∀d ∀j E NICS(d) ∀w.

${{SIDN}\left( {j,w} \right)} = {\frac{\begin{matrix}{\sum\limits_{s = 1}^{C\; 1}{\sum\limits_{i \in {{NICS}{(s)}}}{{{SIDN}\left( {j,w} \right)} \cdot {{PSVU}\left( {{{NSVR}(i)},w} \right)} \cdot}}} \\{{F\left( {s,d,w} \right)} \cdot {{BN}\left( {i,j,w} \right)}}\end{matrix}}{\begin{matrix}{\sum\limits_{s = 1}^{C\; 1}{\sum\limits_{i \in {{NICS}{(s)}}}{{{PSVU}\left( {{{NSVR}(i)},w} \right)} \cdot}}} \\{{F\left( {s,d,w} \right)} \cdot {{BN}\left( {i,j,w} \right)}}\end{matrix}}.}$

There is one exception to this rule for network transmission devices.The visit count is multiplied by the number of messages, then by factorof 2 (two) if the network is full-duplex. Note that networks are notsubject to relocation.

${{DUPLEX}\mspace{14mu}(t)} = \begin{matrix}{2\mspace{14mu}{if}\mspace{14mu}{network}\mspace{14mu} t\mspace{14mu}{is}\mspace{14mu}{fullduplex}} \\{1\mspace{14mu}{otherwise}}\end{matrix}$${{DVCD}\left( {k,w} \right)} = {\frac{{DUPLEX}\mspace{14mu}(t)*{{MC}(t)}}{{{DD}(k)}*{{SD}(t)}}.}$

In step 590 of the transformation method, new service demands estimatesfor servers, devices and network transmission delays for the destinationdata center scenario are computed according to the following paragraphs.

The arrival rate, relative throughput and throughput for the CPU deviceon server t during interval p are calculated as shown in the equationsbelow. Because most variables always change with each interval, thesubscript p is omitted in the remainder of the document.

A(w) ≡ A(w, p) = AB(w) * G(w, p);${{A(0)} = {\sum\limits_{w = 1}^{W}{A(w)}}};$Y(t, w) = (A(w)/A(0)) * SVCD(t, w); and${Y\left( {t,0} \right)} = {\sum\limits_{w = 1}^{W}{{Y\left( {t,w} \right)}.}}$where Y(t,w) is the relative throughput of server t for workload w andY(t,0) is the overall throughput for server t. New service demands arecalculated for CPU's as follows:

PDC(t, w) = SIDC(t, w)/CS(t); and${{PDC}\left( {t,0} \right)} = {\frac{\left( {\sum\limits_{w = 1}^{W}{{Y\left( {t,w} \right)}*{{PDC}\left( {t,w} \right)}}} \right)}{Y\left( {t,0} \right)}.}$

The disk throughputs are computed as:

Y^(′)(k, w) = (A(w)/A(0)) * DVCD(k, w); and${Y^{\prime}\left( {k,0} \right)} = {\sum\limits_{w = 1}^{W}{{Y^{\prime}\left( {k,w} \right)}.}}$where Y′(k,w) is the relative throughput of device k for workload w andY′(k,0) is the overall throughput for device k. Disks are modeled as afixed-rate service center. New disk service demands are calculated asfollows:

PDD(k, w) = SIDD(k, w)/DS(k); and${{PDD}\left( {k,0} \right)} = {\frac{\left( {\sum\limits_{w = 1}^{W}{{Y^{\prime}\left( {k,w} \right)}*{{PDD}\left( {k,w} \right)}}} \right)}{Y^{\prime}\left( {k,0} \right)}.}$

NICs are also modeled as fixed-rate service centers and utilize the samebasic formula.

In the preferred embodiment of the present invention, networktransmission devices are implemented as load-dependent service centers,as are CPU's. Instead of the number of processors, the degree ofconcurrency is determined by the number of streams. The number ofstreams is doubled if the network is full duplex.

A network delay device imposes a fixed delay on every message,regardless of the number of transactions. The response time R is aninput as has been described. The service demand is the same as theresponse time

PDL(n, w) = R(n, w) ⋅ DVCD(n, w); and${{PDL}_{d}\left( {n,0} \right)} = {\frac{\left( {\sum\limits_{w = 1}^{W}{{Y\left( {t,w} \right)}*{{PDL}\left( {n,w} \right)}}} \right)}{Y\left( {t,0} \right)}.}$

A network transmission device is modeled as fixed-rate queuing center inthe same way as Disk and NIC devices. However, because it ischaracterized by slightly different input parameters, there is a uniqueformula to calculate its utilization and service demand

${{{UMT}\left( {n,w} \right)} = \frac{{UDR}\left( {n,w} \right)}{{TS}(n)}};{and}$${{PDT}\left( {n,w} \right)} = {\frac{{{UDR}\left( {n,w} \right)}*{{SC}(n)}}{{DVCD}\left( {n,w} \right)}.}$

In step 600 of the transformation method of the preferred embodiment ofthe present invention, memory service demand and consumption for thedestination data center scenario is computed according to the followingdiscussion.

In general, values of the memory demand can vary between servers. Forworkload reassignment, the weighted demand is calculated in the same wayas device service demands:

${\forall{d{\forall{{wPDM}\left( {d,w} \right)}}}} = {\frac{\sum\limits_{s = 1}^{C\; 1}{{{PDM}\left( {s,w} \right)} \cdot {{SFM}\left( {s,d,w} \right)} \cdot {F\left( {s,d,w} \right)}}}{\sum\limits_{s = 1}^{C\; 1}{F\left( {s,d,w} \right)}}.}$

Note that the memory service demand PDM(s,w) is scaled by SFM(s,d,w) toadjust for server-specific differences in memory consumption.

It is also convenient to define the function G(d,w) to indicate ifworkload w is present on (destination) server d after relocation:

${{G\left( {d,w} \right)} \equiv {1\mspace{14mu}{if}\mspace{14mu}{\sum\limits_{s = 1}^{s = {C\; 1}}{F\left( {s,d,w} \right)}}} > 0};{and}$${{G\left( {d,w} \right)} \equiv {0\mspace{14mu}{if}\mspace{14mu}{\sum\limits_{s = 1}^{s = {C\; 1}}{F\left( {s,d,w} \right)}}}} = 0.$

The sum of core and fixed workload memory requirements on server d afterrelocation are:

${{MCORE}(d)} + {\sum\limits_{w = 1}^{W}{{{MFIXED}\left( {d,w} \right)}*{{G\left( {d,w} \right)}.}}}$

The dynamic memory requirement for workload w on server d is simply theproduct of the throughput and weighted average memory demandMDYN(d,w)=TPUT(d,w)*PDM(d,w).

Thus the total projected memory consumption on destination server d is:

${{MP}(d)} = {{{MCORE}(d)} + \begin{matrix}{\sum\limits_{w = 1}^{W}\left( {{{{MFIXED}\left( {d,w} \right)}*G\left( {d,w} \right)} +} \right.} \\{\left. {{TPUT}\left( {d,w} \right)*{{PDM}\left( {d,w} \right)}} \right).}\end{matrix}}$

The total and dynamic memory utilizations for the destination servers inthe destination data center scenario are, respectively:

${{{UMM}(d)} = \frac{{MP}(d)}{{MC}(d)}};{and}$${{DMWU}\left( {d,w} \right)} = {\frac{{{TPUT}\left( {d,w} \right)}*{{PDM}\left( {d,w} \right)}}{{MC}(d)}.}$

Step 610 of the transformation method 500 takes the output of theprevious steps along with the base configuration parameters contained insource data center 230 and computes standard outputs of a standardqueuing theory solver known in the art and described in section 3.6 ofthe reference work, Computer Performance Modeling Handbook [Stephen S.Lavenburg, Academic Press, 1983]. These standard outputs includethroughputs, utilizations, populations (means and distributions) andmean response times for each device for each workload and become the NewPerformance Results 265 of FIG. 3 and are displayed as requested by theData Center Modeling Wizard 210.

Modeling engine 260 implements the standard queuing theory solver sodescribed to compute the standard outputs. The outputs can be aggregatedto represent arrays of devices, servers or arrays of servers, networksand end-to-end (all devices, servers and networks)—for each workload andfor all workloads together. The response times can be reported asrelative response times (relative to a baseline configuration andreporting period), uncalibrated response times (the standard responsetimes computed by standard queuing network solvers) and calibratedresponse times (calibrated by user-specified known response times). Theoutputs can be displayed via text, tables, and charts of various kinds.

A representative example of the output of modeling engine 260 is a setof relative utilizations for a particular workload displayed as a graphof relative utilization versus time interval p. Those skilled in the artwill understand the many other performance metrics that model engine 260will generate and how those metrics are normally displayed.

Example 1 Server Consolidation Example Consolidate 2 Servers to 1

Assume 3 servers. ServerA has 2 disks (a1 and a2) and one NIC (a1).ServerB has one disk (b1) and two NICS (b1 and b2). ServerC has threedisks (c1,c2,c3) and two NICs (c1,c2)

t server ND(t) DISKS(t) NN(t) NICS(t) 1 ServerA 2 1, 2 1 1 2 ServerB 1 32 2, 3 3 ServerC 3 4, 5, 6 2 4, 5 k server disk DSVR(k) 1 ServerA A1 1 2ServerA A2 1 3 ServerB B1 2 4 ServerC C1 3 5 ServerC C2 3 6 ServerC C3 3K Server NIC NSVR(k) 1 ServerA A1 1 2 ServerB B1 2 3 ServerB B2 2 4ServerC C1 3 5 ServerC C2 3

To consolidate the work on serverA and serverB to ServerC, the CapacityManager user:

-   -   1. Creates a new Server Consolidation scenario.    -   2. Creates a new Reassignment    -   3. Chooses ServerA and ServerB on the “Choose source server”        screen    -   4. Chooses ServerC on the “Choose destination servers” screen

Server consolidation affects all workloads, so for any workload

F(1,3,w)=1 (A to C)

F(2,3,w)=1 (B to C)

F(3,3,w)=1 (work on C stays put)

All other values of F are zero.

Capacity manager implicitly relocates work on peripherals uniformly, soit does not prompt the user for values of BD and BN. Again, allworkloads are affected equally.

In this case, the following values of BD are generated

BD(1,4,w)=⅓ (spread work on disk A1 evenly to the three disks onServerC)

BD(1,5,w)=⅓

BD(1,6,w)=⅓

BD(2,4,w)=⅓ (spread work on disk A2)

BD(2,5,w)=⅓

BD(2,6,w)=⅓

BD(3,4,w)=⅓

BD(3,5,w)=⅓

BD(3,6,w)=⅓

BD(4,4,w)=1 (work on server C disks stays put)

BD(5,5,w)=1

BD(6,6,w)=1

The approach for NIC's is similar

BN(1,4,w)=½

BN(1,5,w)=½

BN(2,4,w)=½

BN(2,5,w)=½

BN(3,4,w)=½

BN(3,5,w)=½

BN(4,4,w)=1

BN(5,5,w)=1

Example 2 Workload Reassignment Example

In the above example, assume two workloads “Sales” (w=1) and “Inventory”(w=2). The Capacity Manager user wishes to model the effects of moving60% of the Sales from Server C to ServerA, while moving 40% of Inventoryfrom ServerC to ServerB.

The sequence of steps from the GUI is:

-   -   1. Create a Workload Reassignment Scenario    -   2. Create a reassignment with the “Specify reassignment details”        screen    -   3. Call the first reassignment “move Sales”    -   4. Select “Sales” workload on the “Select workload to reassign”        screen    -   5. Select ServerC as the source server on “Select source server”        screen    -   6. Enter a value of 60% in the reassignment column for “ServerC”        on the “Select Work to Reassign” screen    -   7. Select Server A as the destination server on the “Select        destination servers” screen    -   8. Create a second reassignment called “Move inventory” with the        “specify reassignment details” screen.    -   9. Select “Inventory” workload on the “Select workload to        reassign” screen    -   10. Select ServerC as the source server on “Select source        server” screen    -   11. Enter a value of 40% in the reassignment column for        “ServerC” on the “Select Work to Reassign” screen    -   12. Select ServerB as the destination server on the “Select        destination servers” screen

The values of the F matrix in this case are:

F(1,1,1)=1 (Sales work on ServerA stays put)

F(1,1,2)=1 (Inventory work on Server A stays put)

F(2,2,1)=1 (Sales on ServerB stays put)

F(2,2,2)=1 (Inventory on ServerB stays put)

F(3,1,1)=0.6 (move 60% of Sales from C to A)

F(3,3,1)=0.4 (leave 40% of Sales on C)

F(3,2,2)=0.4 (move 40% of Inventory from C to B)

F(3,3,2)=0.6 (leave 60% of Inventory on C)

All other values of F are zero.

As with server consolidation, relocation is applied uniformly to disksand NIC's

BD(1,1,1)=1

BD(1,1,2)=1

BD(2,2,1)=1

BD(2,2,2)=1

BD(3,3,1)=1

BD(3,3,2)=1

BD(4,1,1)=½ (spread relocated work evenly)

BD(4,2,1)=½

BD(4,4,1)=1

BD(5,1,1)=½

BD(5,2,1)=½

BD(5,5,1)=1

BD(6,1,1)=½

BD(6,2,1)=½

BD(6,6,1)=1

BD(4,3,2)=1 (only one disk on server B)

BD(4,4,2)=1

BD(5,3,2)=1

BD(5,5,2)=1

BD(6,3,2)=1

BD(6,6,20=1

All other values of BD are zero.

For the NIC activity

BN(1,1,1)=1

BN(2,2,1)=1

BN(3,3,1)=1

BN(4,1,1)=1 (only one NIC on ServerA)

BN(4,4,1)=1

BN(5,1,1)=1

BN(5,5,1)=1

BN(1,1,2)=1

BN(2,2,2)=1

BN(3,3,2)=1

BN(4,2,2)=½ (spread Inventory activity evenly across ServerB NIC's)

BN(4,3,2)=½

BN(4,4,2)=1

BN(5,2,2)=½

BN(5,3,2)=½

BN(5,5,2)=1

While the present invention has been described in terms of specificembodiments thereof, it will be understood in view of the presentdisclosure, that numerous variations upon the invention are now enabledto those skilled in the art, which variations yet reside within thescope of the present teaching. Accordingly, the invention is to bebroadly construed, and limited only by the scope and spirit of theclaims now appended hereto.

The invention claimed is:
 1. A method of capacity planning for servermigration from a first server system characterized by a sourceconfiguration comprising a set of source parameters, an original set ofworkloads and a set of service demands associated to a set of devices,to a second server system, the method comprising: specifying adestination configuration of the second server system; transforming theset of source parameters into a set of destination parameters for thedestination configuration by scaling a service demand in the set ofservice demands into a speed independent service demand parameteraccording to: choosing a speed benchmark parameter associated with adevice in the set of devices, and multiplying the speed benchmarkparameter by the service demand to arrive at the speed independentservice demand parameter; and deriving a performance model for thedestination configuration based on the set of destination parameters andthe speed independent service demand parameter.
 2. The method of claim 1wherein specifying a destination configuration further comprises:consolidating a set of source server in the first server system into aset of destination servers in the second server system; reassigning aworkload in the original set of workloads to the set of destinationservers; changing a source server configuration into a destinationserver configuration; and scaling the workload.
 3. The method of claim 2wherein consolidating a set of source server further comprises: defininga destination data center scenario; and, selecting a new workloadreassignment from a list of premises defined reassignments.
 4. Themethod of claim 2 wherein reassigning a workload comprises: defining adestination data center scenario; choosing a first workload to reassignfrom a first server; and reassigning the first workload to a secondserver according to the destination data center scenario.
 5. The methodof claim 1 further comprising assigning a single server as a sourceserver and a destination server.
 6. The method of claim 1 whereintransforming comprises: selecting a desired number of CPUs in thedestination configuration; and, adjusting a performance parameteraccording to the desired number of CPUs.
 7. The method of claim 1wherein transforming comprises calculating an increased memory usage asa result of a workload change.
 8. The method of claim 1 whereinspecifying a destination configuration further comprises specifying athread level parallelism.
 9. The method of claim 1 wherein specifying adestination configuration further comprises: facilitating the selectionof a source server from the first server system in a graphical userinterface; and facilitating the selection of a destination server forthe second server system in the graphical user interface.
 10. The methodof claim 9 wherein specifying a destination configuration furthercomprises: facilitating the specification of an attached device for thedestination server in the graphical user interface; and, facilitatingthe specification of a threshold profile for the attached device in thegraphical user interface.
 11. The method of claim 10 whereinfacilitating the specification of an attached device further compriseschanging one of: a CPU device from the source configuration; a memoryconfiguration from the source configuration; a disk drive device fromthe source configuration; and a network interface device from the sourceconfiguration.
 12. The method of claim 1 wherein choosing a speedbenchmark parameter includes choosing a CPU SPEC rating as the speedbenchmark parameter.